home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / winsock / maillist / 94-03.Z / 94-03 / text0328.txt < prev    next >
Encoding:
Text File  |  1994-03-30  |  23.5 KB  |  586 lines

  1.              Frequently Asked Questions About
  2.             Windows Sockets Version 1.1
  3.                    23 Mar 1994
  4.  
  5.   This FAQ has been put together by Mark Towfiq, with much-appreciated
  6. assistance from Jay Allard, Bruce Backman, Paul Brooks, Martin Hall,
  7. Simon Hewison, Mike Morse, Bob Quinn, Ed Schwalenberg, Bill Tang, Dave
  8. Treadwell, and Fred Whiteside.  If you have any modifications to this
  9. FAQ, send them to towfiq@East.Sun.Com, and I will fold them into the
  10. next revision.
  11.  
  12.   First of all, the questions:
  13.  
  14. 1.    What is Windows Sockets?
  15. 2.    What is the latest version?
  16. 3.    When is the next rev of the specification?  Why not sooner?
  17. 4.    Where can I get a/the WINSOCK.DLL?
  18. 5.    Why isn't there just one WINSOCK.DLL?  Do I need a TCP/IP already to
  19.       use it?
  20. 6.    Where can I contact Windows Sockets application and implementation
  21.       vendors?  (include list of address, phone contacts)
  22. 7.    Where can I get sample apps and tests?
  23. 8.    Will Windows Sockets be in _____?
  24. 8.1.  Will Windows Sockets be in Windows NT?
  25. 8.2.  Will Windows Sockets be in Windows for Workgroups?
  26. 8.3.  Will Windows Sockets be in DOS?
  27. 8.4.  Will Windows Sockets be in Unix?
  28. 8.5.  Will Windows Sockets be in Win32s?
  29. 9.    What about standard APIs for ____?
  30. 9.1.  What about standard APIs for FTP?
  31. 9.2.  What about standard APIs for Telnet?
  32. 9.3.  What about standard APIs for SNMP?
  33. 9.4.  What about standard APIs for RPC?
  34. 9.5.  What about standard APIs for TLI/XTI?
  35. 10.1. Does Windows Sockets work over protocols other than TCP/IP?
  36. 10.2. Will it?
  37. 11.   Why no SOCK_RAW?
  38. 12.   Why isn't it possible to share sockets between tasks?
  39. 13.1. How do I get my IP address?
  40. 13.2. Why no SIOCGIFADDR?
  41. 14.   When should I use blocking vs. nonblocking sockets?
  42. 15.   What about other socket options that BSD supports?  Ioctls?
  43. 16.   How can I get the local username?
  44. 17.   Do I need to initialize the WSAData structure before calling
  45.       WSAStartup?
  46. 18.   If I write a Windows Sockets program for DOS, will I be able to
  47.       communicate with a Sockets program on UNIX?
  48. 19.   Is it possible to create sockets that map to a dll rather than an
  49.       application?  I have tried a WSAStartup() as part of my LibMain, but
  50.       the sockets that are created are owned by the application, not by the
  51.       DLL. It would be desirable for me to have some of the sockets that
  52.       are opened have "A Global (DLL wide) Scope".
  53. 20.   A *Class* of questions that could be answered are related to porting
  54.       extant BSD applications to Windows Sockets: "How to I implement the
  55.       xxxx function call in my Windows Sockets application?" (e.g. fcntl(),
  56.       readv(), etc).
  57. 21.   Is there a Pascal/Visual Basic/Visual Cobol header file for Windows
  58.       Sockets?
  59. ----------------------------------------------------------------------
  60. 1.  What is Windows Sockets?
  61.  
  62. Answer: The Windows Sockets specification defines a network programming
  63. interface for Microsoft Windows which is based on the "socket" paradigm
  64. popularized in the Berkeley Software Distribution (BSD) from the University
  65. of California at Berkeley.  It encompasses both familiar Berkeley socket
  66. style routines and a set of Windows-specific extensions designed to allow
  67. the programmer to take advantage of the message-driven nature of Windows.
  68.  
  69. The Windows Sockets Specification is intended to provide a single API to
  70. which application developers can program and multiple network software
  71. vendors can conform.  Furthermore, in the context of a particular version
  72. of Microsoft Windows, it defines a binary interface (ABI) such that an
  73. application written to the Windows Sockets API can work with a conformant
  74. protocol implementation from any network software vendor.  This
  75. specification thus defines the library calls and associated semantics to
  76. which an application developer can program and which a network software
  77. vendor can implement.
  78.  
  79. Network software which conforms to this Windows Sockets specification will
  80. be considered "Windows Sockets Compliant".  Suppliers of interfaces which
  81. are "Windows Sockets Compliant" shall be referred to as "Windows Sockets
  82. Suppliers".  To be Windows Sockets Compliant, a vendor must implement 100%
  83. of this Windows Sockets specification.
  84.  
  85. Applications which are capable of operating with any "Windows Sockets
  86. Compliant" protocol implementation will be considered as having a "Windows
  87. Sockets Interface" and will be referred to as "Windows Sockets
  88. Applications".
  89.  
  90. 2.  What is the latest version?
  91.  
  92. Answer: The latest version of the specification is 1.1.
  93.  
  94. 3.  When is the next rev of the specification?  Why not sooner?
  95.  
  96. Answer: The next rev. (2.0) will not be until towards the end of 1993.  We
  97. need 1.1 of the API to become firmly settled and implemented first.
  98.  
  99. 4.  Where can I get a/the WINSOCK.DLL?
  100.  
  101. Answer: You can most probably get one from the same place you got your
  102. TCP/IP software from.
  103.  
  104. 5.  Why isn't there just one WINSOCK.DLL?  Do I need a TCP/IP already
  105.     to use it?
  106.  
  107. Answer: The Windows Sockets specification defines the top level of the DLL,
  108. the part which is called by user programs.  The method a given WINSOCK.DLL
  109. will use to access TCP/IP (or NetWare, or AppleTalk, or DECNet ...) depends
  110. on the networking package you have installed, and therefore must vary.  A
  111. WINSOCK.DLL is therefore just an interface to whatever existing protocol
  112. you already have installed.  An illustration would help:
  113.  
  114.        +---------------------------------+
  115.        |  WinSock compliant application  |
  116.        +---------------------------------+
  117.        +---------------------------------+ <--- WinSock API
  118.        |       Windows Sockets DLL       |
  119.        +---------------------------------+
  120.        +---------------------------------+ <--- Protocol Stack API
  121.        |   Protocol Stack (e.g. TCP/IP)  | (typically proprietary)
  122.        +---------------------------------+
  123.        +---------------------------------+ <--- Hardware Driver API
  124.        |        Hardware Driver          |   (Packet Driver, NDIS, ODI,
  125.        +---------------------------------+    or proprietary)
  126.        +---------------------------------+ <--- Hardware Interface
  127.        |   Network (hardware) Interface  |    (hardware specific)
  128.        +---------------------------------+
  129.                        |
  130.                        +----> network
  131.  
  132. 6.  Where can I contact Windows Sockets application and implementation
  133. vendors?  (include list of address, phone contacts)
  134.  
  135. Answer:
  136.  
  137.     Date: Tue, 6 Apr 93 12:53:37 PDT
  138.     From: tang@documentum.com (Bill Tang)
  139.     To: winsock@Microdyne.COM
  140.     Subject: vendor list (long)
  141.  
  142.     Thanks to all that responded to my previous inquiry of vendor
  143.     implementations. I am posing a summary and will keep the list updated
  144.     if I receive more information.
  145.     -------------------------------------------------------------------------
  146.     SUMMARY
  147.     -------------------------------------------------------------------------
  148.     Company            Shipping?    Notes
  149.     -------------------------------------------------------------------------
  150.     3Com Corp            Yes
  151.     Beame & Whiteside        Yes
  152.     Distinct Corp        Yes    
  153.     FTP Software        Yes        DLL available from vax.ftp.com
  154.     Frontier Tech        Yes
  155.     IBM                Yes
  156.     JSB Corporation        Yes
  157.     Lan Design            Yes
  158.     Lanera Corp            Yes
  159.     Microdyne            Yes
  160.     Microsoft(W NT 32b)        Yes
  161.     Microsoft(W NT 16b)        ???
  162.     Microsoft(W 3.x 16b)    ???
  163.     NetManage            Yes
  164.     Network Research        ???
  165.     Novell            Yes
  166.     Spry            Yes
  167.     SunSelect            Yes
  168.     Ungermann Bass        Yes
  169.     Walker Richer Quinn        Yes
  170.     Wollongong            Yes
  171.  
  172. 7.  Where can I get sample applications and tests?
  173.  
  174. Answer: Files and information related to the Windows Sockets API are
  175. available via FTP (user: "anonymous", password: your e-mail address)
  176. on the host SunSite.UNC.EDU, in /pub/micro/pc-stuff/ms-windows/winsock.
  177. Note: if you do not have FTP access to the Internet, send a message
  178. with the word "help" in the body to either ftpmail@SunSite.UNC.Edu, or
  179. ftpmail@DECWRL.DEC.Com (in the UK mail to ftpmail@doc.ic.ac.uk), to
  180. obtain information about the FTP to Mail service there.
  181.  
  182. 8.  Will Windows Sockets be in _____?
  183.  
  184. 8.1.  Will Windows Sockets be in Windows NT?
  185.  
  186. Answer: Yes.  In 16 and 32-bit versions.
  187.  
  188. 8.2.  Will Windows Sockets be in Windows for Workgroups?
  189.  
  190. Answer: Yes.
  191.  
  192. 8.3.  Will Windows Sockets be in DOS?
  193.  
  194. Answer: Paul Brooks of TurboSoft (paul@abccomp.oz.au) tells me:
  195.  
  196.     As for a Windows Sockets for DOS - we have a library that is
  197.     pretty much complete. The goal was to produce a DOS library and
  198.     Binary API which would allow developers to code applications using
  199.     the Windows Sockets 1.1 spec. and have it run exactly the same
  200.     under DOS as Windows - blocking and non-blocking modes,
  201.     Asynchronous calls, the works. Apart from some AsyncGetXXXbyYYY
  202.     calls the rest works, although it is not possible to capture all
  203.     the Windows-specific semantics of some areas.
  204.  
  205. I am sure you can contact him for more information.  JSB also has a
  206. standardized Berkeley Sockets API for DOS which provides access to all
  207. TCP/IP implementations.
  208.  
  209. 8.4.  Will Windows Sockets be in UNIX?
  210.  
  211. Answer: Well, since it came from BSD UNIX, there's not much need.
  212.  
  213. 8.5.  Will Windows Sockets be in Win32-S?
  214.  
  215. Answer: Yes, Win32s 1.1 contains a thunking layer that converts 32-bit
  216. Windows Sockets calls to 16-bit Windows Sockets.  It should work on
  217. top of any 16-bit WINSOCK.DLL.
  218.  
  219. 9.  What about standard APIs for ____?
  220.  
  221. 9.1.  What about standard APIs for FTP?
  222.  
  223. Answer: Not yet.
  224.  
  225. 9.2 What about standard APIs for Telnet?
  226.  
  227. Answer: Not yet.
  228.  
  229. 9.3 What about standard APIs for SNMP?
  230.  
  231. Answer: In the works.  Send e-mail to listserv@SunSite.UNC.EDU with
  232. "subscribe winsnmp" in the body of the message to join the list.
  233.  
  234. 9.4 What about standard APIs for RPC?
  235.  
  236. Answer: Microsoft will be providing an implementation of DCE RPC.  Also in
  237. the works is the definition of a standard implementation of ONC RPC (known
  238. as RPC for Windows) which will be made available by multiple vendors.  To
  239. contribute to the discussion, send email to rpc4win@wco.ftp.com.
  240.  
  241. 9.5 What about standard APIs for TLI/XTI?
  242.  
  243. Answer: No, not yet.  Vendors chose to do Windows Sockets because of the
  244. sockets application and knowledge base, however anyone out there is free to
  245. try a Windows TLI/XTI Specification.
  246.  
  247. 10.1.  Does Windows Sockets work over protocols other than TCP/IP?
  248.  
  249. Answer: Yes, it does.  But we know of no vendors supplying one currently.
  250.  
  251. 10.2.  Will it?
  252.  
  253. Answer: Yes.  Windows NT will include mechanisms for multiple protocol
  254. support in Windows Sockets, both 32-bit and 16-bit.
  255.  
  256. 11.  Why no SOCK_RAW?
  257.  
  258. Answer: SOCK_RAW is optionally implemented by many major Windows Sockets
  259. vendors.  It is not mandated now because: 1) not every stack vendor can
  260. supply a complete SOCK_RAW interface, and 2) we did not have time to define
  261. the minimal subset every vendor could provide (e.g. maybe just ICMP).
  262.  
  263. 12.  Why isn't it possible to share sockets between tasks?
  264.  
  265. Answer: The real answer is that it wasn't considered sufficiently important
  266. for 1.1, but is high on the list for inclusion in 2.0.
  267.  
  268. 13.1.  How do I get my IP address?
  269.  
  270. Answer: Do a gethostbyname() on the output from gethostname().
  271.  
  272. 13.2.  Why no SIOCGIFADDR?
  273.  
  274. Answer: It was not included because there were concerns it could not be
  275. supported across platforms.  It may be included in version 2.0 of the spec.
  276.  
  277. 14.  When should I use blocking vs. non-blocking sockets?
  278.  
  279. Answer: Try to use non-blocking sockets whenever possible; certainly if you
  280. are coding a Windows application from scratch.  Blocking sockets should
  281. only be used when trying to maintain portability between UNIX/MS-DOS and
  282. Windows.
  283.  
  284. 15.  What about other socket options that BSD supports?  Ioctls?
  285.  
  286. Answer: Some vendors may support them.  Do not rely on ones not explicitly
  287. mentioned in the specification, however.
  288.  
  289. 16.  How can I get the local username?
  290.  
  291. Answer: Based on a suggestion from Simon Hewison
  292. (p0063886@cs3.oxford-brookes.ac.uk), one idea is to call WNetGetUser()
  293. in the NETWORK.DRV.  If a vendor has supplied a NETWORK.DRV then this
  294. will work, if not you can just use some other method.  Thus you could
  295. write a bit of code thus:
  296.  
  297.     WNetGetUser(szNetUserId,sizeof(szNetUserId);
  298.     if (strlen(szNetUserId)==0) {
  299.         /* call some other method of getting
  300.            userid, eg. the lan manager call NetWkstaGetInfo */
  301.     }
  302.  
  303.   Information on this API call is in the Windows Device Driver Adaption
  304. Guide.
  305.  
  306. 17.  Do I need to initialize the WSAData structure before calling
  307. WSAStartup?
  308.  
  309. Answer: No, WSAStartup does not retrieve the contents of the WSAData
  310. structure pointed to, it fills it in.
  311.  
  312. 18.  If I write a Windows Sockets program, will I be able to communicate
  313. with a Sockets program on UNIX or any other non Windows platform?
  314.  
  315. Answer: Absolutely!  This common question is the result of confusing
  316. protocols with the APIs; communicating programs need not have been
  317. created with the same APIs, as long as they are using the same
  318. (transport & network) protocols.
  319.  
  320. 19.  Is it possible to create sockets that map to a dll rather than an
  321. application?  I have tried a WSAStartup() as part of my LibMain, but the
  322. sockets that are created are owned by the application, not by the DLL. It
  323. would be desirable for me to have some of the sockets that are opened have
  324. "A Global (DLL wide) Scope".
  325.  
  326. Answer: The way this situation has been dealt with by developers is to have
  327. your DLL create a "helper process" which will perform all Windows Sockets
  328. operations on behalf of your applications (thereby having all sockets owned
  329. by the helper process' task).
  330.  
  331. 20.  A *Class* of questions that could be answered are related to porting
  332. extant BSD applications to Windows Sockets: "How to I implement the xxxx
  333. function call in my Windows Sockets application?" (e.g. fcntl(), readv(),
  334. etc).
  335.  
  336. Answer: In general, you will have to code such functions yourself, although
  337. it would not hurt to suggest them for the next revision of the
  338. specification as well.
  339.  
  340. 21.  Is there a Pascal/Visual Basic/Visual Cobol header file for Windows
  341. Sockets?
  342.  
  343. Answer: The Pascal and Visual Basic forms are already in the FTP
  344. archive.  Look there for any other header files that people may have
  345. developed so far.  It should be pointed out that not all the Winsock
  346. functions can be called from Visual Basic and the subset that can be
  347. called are not really enough for a true app (for example, you can't
  348. call gethostbyname()).  To use Winsock from VB requires a translation
  349. DLL that will probably have to be written in C.  To date, there is no
  350. public domain implementation, although several vendors have announced
  351. toolkits for Winsock for VB.
  352. From news@bigblue.oit.unc.edu Thu Mar 24 11:58:21 1994
  353. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  354.           id AA21539; Thu, 24 Mar 1994 08:15:46 -0500
  355. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  356.           id AA26805; Thu, 24 Mar 1994 07:05:30 -0500
  357. Received: from GATEWAY by bigblue with netnews
  358.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  359. To: winsock@sunsite.unc.edu
  360. Date: Thu, 24 Mar 1994 11:58:21 +0000
  361. From: philc@hipstech.demon.co.uk (Phil Cramp)
  362. Message-Id: <764510301snz@hipstech.demon.co.uk>
  363. Organization: AT&T Istel H.I.P.S. Technical Support
  364. Sender: ses
  365. Reply-To: philc@hipstech.demon.co.uk
  366. Subject: NCSA WinTel and Winsock problem.
  367.  
  368.  
  369. I am trying to get the NCSA WinTel program to work with the NCSA
  370. windows sockets dll, but achieving only a "General Protection fault"
  371. when I try to connect to a network host - can anyone enlighten me?
  372. Details:
  373. Machine:    NCR System 3230 486SX25
  374.         8Mb Ram/120Mb disk
  375.         EVGA (1024x768 - interlaced)
  376.         3Com 3c509-COMBO Network card, Twisted pair i/f.
  377.         - Packet driver from 3com
  378.         - IO address 0x300
  379.         - IRQ 10
  380.         - Software interrupt 0x65
  381.         MS-Windows 3.1 / DOS 6.0 (not doublespaced)
  382.         NCSA WinTel, Telnet for Windows
  383.         NCSA Winsock - sockets for MS-Windows, version 1 Beta 2
  384.  
  385. The driver is loaded as recommended in the documnetation:
  386.     3c5x9pd -w 0x65
  387. and reports loaded OK with values matching those above.
  388.  
  389. ncsabind reports loaded at software interrupt 0x66
  390.  
  391. load windows - ok.
  392.  
  393. Clicking on WINTEL icon produces error - cannot write to AUX, with <cancel>
  394. or <retry> buttons available - I click <cancel> to avoid a loop!
  395. This reveals the "open connection" dialog box, but with no pull-down list
  396. or 'default' host specified. I enter one of our hostnames (as specified
  397. in config.tel) and click <OK>.
  398.  
  399. An "APPLICATION ERROR" box pops-up!, with the following message -
  400.     WINTEL caused a General Protection fault in
  401.     module winsock.dll at 0001:1839
  402.  
  403. Is there anything I am missing/should have loaded/should not have loaded?
  404. -- 
  405. Phil Cramp                      philc@hipstech.demon.co.uk
  406. AT&T Istel Ltd., Redditch, U.K.
  407. #include "std/disclaimer"       Reedemable Value UKP0.01
  408. From news@bigblue.oit.unc.edu Thu Mar 24 08:41:50 1994
  409. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  410.           id AA25355; Thu, 24 Mar 1994 08:41:50 -0500
  411. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  412.           id AA17056; Thu, 24 Mar 1994 08:31:43 -0500
  413. Received: from GATEWAY by bigblue with netnews
  414.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  415. To: winsock@sunsite.unc.edu
  416. Date: Thu, 24 Mar 1994 14:50:03
  417. From: sblignau@infocomp.csir.co.za (Blignaut, Shaun)
  418. Message-Id: <sblignau.1.000ED5FC@infocomp.csir.co.za>
  419. Organization: CSIR
  420. Sender: ses
  421. Subject: Looking for WINCOD23 (3/3)
  422.  
  423. Hi !
  424.  
  425. About a week or two ago there were three postings of Wincod23.  I only managed 
  426. to get the first two. Is it possible for someone to post the third part to me 
  427. directly.
  428.  
  429. Much appreciated.
  430.  
  431. Shaun
  432.  
  433. sblignau@infocomp.csir.co.za
  434. shaun@wabe.csir.co.za
  435. From news@bigblue.oit.unc.edu Thu Mar 24 12:20:20 1994
  436. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  437.           id AA00804; Thu, 24 Mar 1994 09:11:51 -0500
  438. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  439.           id AA08660; Thu, 24 Mar 1994 08:48:15 -0500
  440. Received: from GATEWAY by bigblue with netnews
  441.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  442. To: winsock@sunsite.unc.edu
  443. Date: 24 Mar 1994 12:20:20 GMT
  444. From: tom@fatty.law.cornell.edu (Thomas R. Bruce)
  445. Message-Id: <2ms0i4INNnvf@newsstand.cit.cornell.edu>
  446. Organization: Cornell University
  447. Sender: ses
  448. References: <jnlin.17.001D5BB6@netrd.net.tw>
  449. Subject: Re: Cello Ver. 1.0
  450.  
  451. Lin Jyun-Naih (jnlin@netrd.net.tw) wrote:
  452. : Hi,
  453.  
  454. :      I am just using Cello ver. 1.0 and when I lunched the gopher, 
  455. : it displayed the first menu of the gopher server, but when I choosed
  456. : the item "Other Gopher Servers". It hanged and could not go down.
  457. : I also used Cello ver. 0.9 and it worked fine and could go to any gopher
  458. : server. Is there any bug in Cello ver. 1.0?
  459.  
  460. : J.N.Lin
  461.  
  462. There was a bug in Cello 1.0 which caused it to misbehave with Gopher+
  463. servers.  It's fixed in 1.01a, currently available from
  464. ftp.law.cornell.edu, in the /pub/LII/Cello directory.
  465.  
  466. Best,
  467. Tb.
  468.  
  469. Thomas R. Bruce
  470. Legal Information Institute
  471. From news@bigblue.oit.unc.edu Thu Mar 24 13:30:50 1994
  472. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  473.           id AA00811; Thu, 24 Mar 1994 09:11:53 -0500
  474. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  475.           id AA09331; Thu, 24 Mar 1994 09:02:38 -0500
  476. Received: from GATEWAY by bigblue with netnews
  477.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  478. To: winsock@sunsite.unc.edu
  479. Date: Thu, 24 Mar 1994 13:30:50 GMT
  480. From: lattice@world.std.com (Lattice Trading Inc.)
  481. Message-Id: <Cn687F.KKo@world.std.com>
  482. Organization: The World Public Access UNIX, Brookline, MA
  483. Sender: ses
  484. References: <2ml9j2$ahu@thor.cs.umass.edu>
  485. Subject: Re: How Does one detect server closing socket
  486.  
  487. In article <2ml9j2$ahu@thor.cs.umass.edu>,
  488. Robert Cook <cook@cs.umass.edu> wrote:
  489. >I have a server that times out a connection if its been idle
  490. >for more then a certain time.  So I'm trying to build a client
  491. >that will handle this.  I thought if I tried to send data to a 
  492. >disconnected socket that send() would return SOCKET_ERROR, but
  493. >that's not happening. Noting that the Winsock specs for send() 
  494. >states, "Note that the successful  completion of a send() does
  495. >not indicate that the data was successfully delivered.",  I 
  496. >tried setting TCP_NODELAY on the socket and that
  497. >didn't work.  I tried using select and that didn't work.  The only
  498. >time I know that the socket is disconnected is when I use the recv()
  499. >command.  I could probably write a function that would ping the
  500. >connection
  501. >and the recv() would return SOCKET_ERROR, but that means I would first
  502. >ping the connection everytime I wanted to send data.  That seems pretty
  503. >inefficent.
  504. >
  505. >So how do other people do it?  How can the client detect that
  506. >the server has closed the connection?
  507. >
  508.  
  509. I went through this on both the Unix (server) side and the PC (client)
  510. side.  I have a solution that works, but I'm not sure that it is the
  511. best one.  I'm interested in hearing any criticism:
  512.  
  513. 1) Set the SO_KEEPALIVE socket level option.  This will send an empty
  514.    message every 45 seconds (BSD) and expect a response within 6
  515.    minutes (BSD).  If it times out the next operation on the socket
  516.    should fail.
  517.  
  518. 2) The asynch select doesn't get notified if a timeout happens unless
  519.    you have written data to the socket (speculation here).  I just have
  520.    a timer that tries to write data every once in a while to make
  521.    sure a timeout hasn't occurred.
  522.  
  523. -- Les Walker
  524.    lattice@world.std.com
  525. From news@bigblue.oit.unc.edu Thu Mar 24 13:50:29 1994
  526. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  527.           id AA05665; Thu, 24 Mar 1994 09:41:59 -0500
  528. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  529.           id AA16886; Thu, 24 Mar 1994 09:16:47 -0500
  530. Received: from GATEWAY by bigblue with netnews
  531.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  532. To: winsock@sunsite.unc.edu
  533. Date: Thu, 24 Mar 1994 13:50:29 GMT
  534. From: dbasinge@bronze.ucs.indiana.edu (D. Michael Basinger)
  535. Message-Id: <Cn6949.Iqq@usenet.ucs.indiana.edu>
  536. Organization: Indiana University, Bloomington IN
  537. Sender: ses
  538. Subject: Converting .newsrc to news.ini
  539.  
  540. I'm looking for a program or shell script that would convert a unix
  541. .newsrc file to a Trumpet news.ini file (and visa versa). I have heard
  542. of one written in perl, but have been unable to find it.
  543.  
  544. thanks,
  545. mike
  546. -- 
  547. D. Michael Basinger:     Not speaking for I.U. or the School of HPER
  548. Computer Specialist    dbasinge@bronze.ucs.indiana.edu
  549. School of HPER        dbasinge@nations.ucs.indiana.edu (NeXT Mail)
  550. Indiana University    Phone: (812) 855-1562    Fax: (812) 855-4983
  551. From news@bigblue.oit.unc.edu Thu Mar 24 13:53:39 1994
  552. Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
  553.           id AA16809; Thu, 24 Mar 1994 10:41:55 -0500
  554. Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
  555.           id AA16071; Thu, 24 Mar 1994 10:12:55 -0500
  556. Received: from GATEWAY by bigblue with netnews
  557.     for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
  558. To: winsock@sunsite.unc.edu
  559. Date: Thu, 24 Mar 1994 13:53:39 GMT
  560. From: ssulliva@opal.tufts.edu (Sean Sullivan)
  561. Message-Id: <ssulliva.18.0008E533@opal.tufts.edu>
  562. Organization: Lamont-Doherty Earth Observatory
  563. Sender: ses
  564. References: <THOMASG.3099.2D90A28A@staff.tc.umn.edu>
  565. Subject: Re: Trumpet News reader and Eudora Problem
  566.  
  567. >I started having trouble with version 1.0B Trumpet News reader for Windows 
  568. >about a month ago.  After doing some deep thinking I remembered that is about 
  569. >the same time I started using Eudora.
  570.  
  571. >What seems to be happening is if I run Eudora BEFORE I run Trumpet News reader 
  572. >I run a good chance of Trumpet causing a general protection fault in 
  573. >KRNL386.EXE right after the info box of Trumpet.  If I run Eudora After 
  574. >starting the news reader every thing seems fine.
  575.  
  576. >Of course one would want to leave Eudora running in the background and not 
  577. >have to restart Windows to check out the news groups.
  578.  
  579. >Is anyone else having this problem?
  580.  
  581. >Does anyone have any ideas?
  582.  
  583. I am running Trumpet Newsreader and Eudora simultaneously with no problems.
  584.  
  585.  
  586.